fix(core): stabilize collinear wall junction ordering - #596

Approved and merging — thank you @tomatotomata, and welcome. This is the right fix and the right size for it.

Verified rather than assumed:

• The test genuinely fails on main, and not on map insertion order — I reverted wall-mitering.ts to main while keeping your test, and it fails with real geometry differences (wide's left corner at y: 0.3 vs 0.1, and the mirrored change on narrow's right). That's the pairing flip the issue described, so this test would catch a regression rather than just pass alongside the fix.
• wallId is the correct tie-break key, and it's what's on ProcessedWall — no plumbing needed. Stable across reload and across peers, unlike thickness, which isn't unique.
• Passthrough walls push two entries with the same wallId (v1 and v2), so the comparator can still return 0 for a pair. Not a problem: the two entries are 180° apart, so their angles differ and the tie-break is never reached for them. Worth knowing it's true by construction rather than by luck.
• processedWalls.sort is the only order-sensitive comparator left in the file. The other one at line 214 keys on an explicit wallOrder map, which is already deterministic.
• The miter cache is safe. I checked level-miter-cache.ts because the issue flagged it: sameMiterInputs compares positionally, so a reordered array is a cache miss, never a stale hit. With this fix the recompute now returns identical data, which is exactly the property the cache wanted.

Full gate green locally: check 1601 files clean, check-types 9/9, test 12/12 tasks (945 nodes tests + 12 mitering), build 7/7.

Agreed on scoping out the near-equal-angle epsilon, and on reflection it belongs out of scope for a stronger reason than "different change": it isn't a determinism gap at all. I raised it in the issue as an open question, and working through your fix answers it. angle is a pure function of the wall's own geometry, so two walls differing by 1e-16 sort consistently every time — the order is stable, it's just not the order a human would call "obvious". What I was actually describing there is miter quality at shallow angles, which MITER_LIMIT already handles by falling back to a square joint. So Closes #581 is right and I'm letting it close; no follow-up needed. An epsilon tie-break would also make the comparator non-transitive, which is undefined behavior for Array.prototype.sort — so it'd be a bucketing change, not a comparator tweak, and there's no reason to make it.

One note on your validation commands: npx --yes bun@1.3.0 test <file> works, but you can run the whole repo gate with bun run check && bun run check-types && bun run test && bun run build — that's what CI runs, and it catches cross-package type breakage that a single-file test run won't. Not needed here; your change was clean through all four.

Merged as 163ef0be, and #581 closed with it.

One process note for next time: this was open as a draft, which is why CI didn't run until I approved the workflow (first-time contributor from a fork needs that regardless) and why the merge initially bounced. The body read as a finished submission — full validation output and an explicit scope note — so I marked it ready myself rather than bouncing it back to you. If a PR is ready for review, opening it undrafted gets it looked at sooner.

Thanks again. If you want another in the same area, #588 (batching a level's static walls per material) is labelled help wanted and is the natural next step in the same wall-geometry path you just worked in.